Development of 3rd Generation Mobile Communication Technology makes it possible to provide services with a higher data transfer speed than 2nd Generation Mobile Communication does, and further support many new services, such as video telephone, downloading pictures and high speed Internet browsing, etc. Some services thereof have the following common features: it is possible to send corresponding data simultaneously to all subscribers who customized the service in radio network, for instance, sending weather forecast, short newsreel and sports performance collection etc. Based on the feature that data of these services can be sent at the same time, 3rd Generation Mobile Communication introduces the concept of multicast/broadcast.
As shown in FIG. 1, for a middle node, for example, node 10, no matter how many downstream nodes expect to receive data, its upstream node always transmits one copy of the data to the middle node; after receiving the data, the middle node replicates the data into several copies according to the number of the downstream nodes that expect to receive the data and distributes the data to the each downstream node, for example, the downstream nodes of node 10 expecting to receive the data containing node 101 and node 102, so node 10 duplicates two copies of the received data. In this way, each branch of MBMS transmission tree has only one copy of data to transmit, sharing one copy of transmission source, and so does the data transmission of the root node and its downstream nodes. The difference between broadcast service and multicast service is: multicast service transmits corresponding information only to the subscribers who subscribed to particular information, while broadcast service transmits information to all the subscribers in radio network. It can be seen from the above description that providing the same information to a great number of subscribers through MBMS bearer service can save network sources greatly.
FIG. 2 illustrates the radio network architecture which supports MBMS bearer service, wherein the network entities include a Broadcast-Multicast Service Center (BM-SC) 201 which supports multicast/broadcast service, a Gateway GPRS Support Node (GGSN) 202, a Serving GPRS Support Node (SGSN) 203, a Universal Terrestrial Radio Access Network (UTRAN) 204 of Universal Mobile Telecommunication System (UMTS), a GSM/EDGE Radio Access Network (GERAN) 205 in Global System of Mobile communication (GSM) and User Equipment (UEs) 206 and 207. As shown in FIG. 2, in the conventional 3rd Generation Partnership Project (3GPP) frame, BM-SC 201 is connected to GGSN 202 through a Gmb interface or a Gi interface, where one BM-SC 201 can be connected to several GGSNs as GGSN 202. GGSN 202 is connected to SGSN 203 through a Gn/Gp interface, where one GGSN 202 can be connected to several SGSNs as SGSNs 203. SGSN 203 can be connected to UTRAN 204 through an Iu interface and UTRAN 204 is connected to UE 206 through a Uu interface. SGSN 203 can also be connected to GERAN 205 through an Iu/Gb interface, and GERAN 205 is connected to UE 207 through a Um interface. The BM-SC can be a BSC/RNC.
Combining FIG. 1 and FIG. 2, BM-SC 201 is equivalent to a root node of a tree structure. The downstream node of BM-SC 201 is GGSN 202. The downstream node of GGSN 202 is SGSN 203. The downstream nodes of SGSN 203 are UEs 206 and 207. Of course, there can be more than one GGSNs and SGSNs. It is obvious that the data distribution of MBMS bearer service is implemented through a tree structure, which commonly implemented through multiple BSC/RNCs, SGSNs and GGSNs. Furthermore, some bearer resources are needed to be shared between subscribers who use a same MBMS bearer service. Therefore, a uniform QoS is created at each branch of the MBMS distribution tree. For above characteristics, when a new branch of the MBMS distribution tree is created, the QoS of the whole distribution tree should not be affected by this new branch. Accordingly, a QoS negotiation should not be implemented in UMTS network. If the network cannot accept QoS requirements of particular branches, as a result, these branches cannot be created. For instance, when the MBMS bearer capabilities of a particular UE are less than the Required MBMS Bearer Capabilities of a MBMS bear service, the UE will be rejected to use this MBMS bearer service by the network.
In current specification, the BM-SC can transmit the Required MBMS Bearer Capabilities corresponding to an MBMS bearer service through an MBMS Registration Procedure to a GGSN and a SGSN. The Required MBMS Bearer Capabilities may identify the minimum bearer capabilities requested by the UE when the UE receives the MBMS bearer service, that is, the maximum QoS ability that the MBMS bearer service possibly uses. When the UE joins the MBMS bearer service through an MBMS bearer service activation procedure, the network needs to verify whether the MBMS bearer capabilities of the UE satisfy the Required MBMS Bearer Capabilities.
The MBMS Bearer Context is used to store the Required MBMS Bearer Capabilities, which contain all the description information defining an MBMS bearer service and are created at all nodes that bear the MBMS data. As shown in Table 1, the MBMS Bearer Context includes an IP multicast address, an Access Point Name (APN), a Temporary Mobile Group Identification (TMGI), a State, a Required MBMS Bearer Capabilities, a QoS, an MBMS bearer service Area, a List of downstream nodes, a Number of UEs and so on. The IP multicast address identifies an MBMS bearer service described by this MBMS Bearer Context. The APN is an access point name on which this IP multicast address is defined. The TMGI is a temporary mobile group identity allocated to the MBMS bearer service. The State is the state of bearer plane resources, i.e., “Standby” or “Active” state. The Required MBMS Bearer Capabilities refer to the minimum bearer capabilities the UE needs to support. The QoS means Quality of Service required by the MBMS bearer service. The MBMS bearer service Area is the area over which the MBMS bearer service has to be distributed. The List of downstream nodes refers to the List of downstream nodes which requested the MBMS bearer service and to which notifications and MBMS data have to be distributed. The number of UEs means the number of UEs hosted by the node which joined the MBMS bearer service.
TABLE 1BM-ParameterDescriptionRANSGSNGGSNSCIP multicastIP multicast address identifying the MBMSXXXXaddressbearer described by this MBMS BearerContext.APNAccess Point Name on which this IP multicastXXXUndeterminedaddress is defined.TMGITemporary Mobile Group Identity allocatedXXXXto the MBMS bearer service.StateState of bearer plane resources (‘standby’ orUndeterminedXXX‘active’)Required MBMSMinimum bearer capabilities the UE needs toXXXBearersupportCapabilitiesQoSQuality of Service required for the MBMSXXXXbearer service.MBMS bearerArea over which the MBMS bearer serviceXXXXservice Areahas to be distributed.List ofList of downstream nodes that have requestedXXXdownstreamthe MBMS bearer service and to whichnodesnotifications and MBMS data have to beforwarded.Number of UEsNumber of UEs hosted by the node that haveUndeterminedXXUndeterminedjoined the multicast MBMS bearer service.
During the MBMS bearer service activation procedure, the subscriber is registered in the network to be enabled to receive data from a specific multicast MBMS bearer service. The activation is a signaling procedure between the UE and the network, which establishes an MBMS UE Context at UE, SGSN, GGSN and BSC/RNC for each activated multicast MBMS bearer service. The establishment of MBMS UE Context is similar as the establishment of general PDP context. The MBMS UE Context contains particular information of the particular MBMS bearer service which the UE joined. When the UE joins an MBMS bearer service, the MBMS UE Context is created at the UE, SGSN and GGSN. The MBMS UE Context is stored as part of the MM Context of the UE and is stored in the GGSN solely. There is one MBMS UE Context for each MBMS bearer service which the UE joined.
As shown in Table 2, the MBMS UE Context includes an IP multicast address, an APN, a TMGI, a (Network Service Access Point Identity) Linked NSAPI, an IMSI and the like. The IP multicast address identifies an MBMS bearer service which the UE joined. The APN is an access point name on which this IP multicast address is defined. The TMGI is a temporary mobile group identity allocated to the MBMS bearer service. The Linked NSAPI is the NSAPI of the PDP context used by the UE to carry an IGMP/MLD signaling. The IMSI is a subscriber identity. The MBMS_NSAPI is a Network layer Service Access Point Identifier which identifies an MBMS UE Context.
TABLE 2BM-ParameterDescriptionUESGSNGGSNRNCBSCSCIP multicastIP multicastXXXXIu - XXaddressaddress identifyingGb -an MBMS bearernonethat the UE hasjoined.APNAccess PointXXXXIu - XXName on whichGb -this IP multicastnoneaddress is defined.GGSN AddressThe IP address ofXin Usethe GGSNcurrently usedSGSN addressThe IP address ofXSGSNTMGITemporary MobileXXXIu - XGroup IdentityGb -allocated to thenoneMBMS bearer.Linked NSAPINSAPI of the PDPXXcontext used bythe UE to carryIGMP/MLDsignalling.IMSIIMSI identifying(1)(1)X(2)Iu - (2)Xthe user.Gb - (3)TITransactionXXIdentifierMBMS_NSAPINetwork layerXXXXService AccessPoint Identifierwhich identifiesan MBMS UEContext.
In table 2, (1) means that in the UE and SGSN, the IMSI is available within the MM Context which contains the MBMS UE Context. (2) means that the IMSI is available within the UE Context which contains the MBMS UE Context.
As shown in FIG. 3, the activating method of MBMS bearer service according to the prior art includes the steps of:
Step 301: In general, when a UE needs to activate a particular MBMS bearer service, it will create a PDP Context (PDP Context Activation) through an interaction with the network.
If the current UE has created the PDP Context with network, the created PDP Context is directly used. If the current UE has not created the PDP Context with network, the UE will activate a default PDP Context, the type of which is generally best effort. The PDP Context can be a PDP Context used in a basic IP service, such as WAP or Internet access, or can also be a signaling PDP Context used in an IP Multimedia Subsystem (IMS) access. In this embodiment, the GGSN corresponding to the default PDP Context is GGSN1.
Step 302: The current UE transmits an IGMP Joining or MLD Joining to GGSN1 through the created PDP Context, wherein in the message, a particular MBMS bearer service which is expected to receive by the subscriber is identified by the IP multicast address. If IPv4 protocols are adopted, the UE transmits an IGMP Joining to GGSN1. If IPv6 protocols are adopted, the UE transmits an MLD Joining to GGSN1. In this embodiment, IPv4 protocols are adopted.
Step 303: After receiving the IGMP/MLD Joining, GGSN1 transmits an MBMS Authorization Request to request the authorization for data reception of the current UE to a BM-SC. If the authorization request is passed, then the BM-SC transmits an MBMS Authorization Response to GGSN1, and the response carries the APN which is used to activate MBMS UE Context. If the authorization request is not passed, the MBMS Authorization Response transmitted from BM-SC to GGSN1 indicates that the UE cannot be authorized to receive MBMS data and the flow is ended.
Step 304: GGSN1 transmits an MBMS Notification Request to the SGSN, wherein the request includes an IP multicast address, an APN and a Linked NSAPI. The configuration of the Linked NSAPI equals to a PDP Context NASP1 used by GGSN1 when GGSN1 receives the Joining request. The IP multicast address is an IP multicast address in the Joining request of the UE. The APN is likely to be different from the APN of the activated default PDP Context, and under some circumstances, the APN possibly corresponds to another GGSN differing from GGSN1 which receives the IGMP/MLD Joining request. Since GGSN1 can not receive the response, for example the SGSN or the UE does not support the MBMS bearer service, and under these circumstances, GGSN1 needs to startup an MBMS Activation Timer.
Step 305: After receiving the MBMS Notification Request, the SGSN transmits an MBMS Context Activation Request to the UE, which is used to request the UE to activate an MBMS UE Context. The message at least carries an IP multicast address, an APN, a Linked NSAPI and a Transaction Identifier (TI). The Linked NSAPI allows the UE to associate the MBMS UE Context with the PDP context over which the UE sent the IGMP/MLD Joining in Step 302. The TI is selected by the SGSN, value of which is not used by other PDP Context or the MBMS UE Context activated by the UE.
Step 306: After creating the MBMS UE Context, the UE transmits an Activate MBMS Context Request to the SGSN, wherein the message includes an IP multicast address, an APN, an MBMS_NSAPI and MBMS bearer capabilities. The IP multicast address is used to identify startup joined/activated MBMS bearer service The APN indicates a particular GGSN. The MBMS bearer Capabilities are used to identify the maximum QoS which the UE can process. The MBMS_NSAPI is selected by the UE, value of which is not used by other PDP Context or MBMS UE Context activated by the UE.
Step 307: The SGSN transmits an MBMS Notification Response to GGSN1 which transmits an MBMS Notification Request in Step 304. An MBMS UE Context value is carried in this response and the MBMS UE Context value is used to indicate whether the MBMS UE Context is activated successfully. If the activation is not successful, the MBMS UE Context value indicates that failure of activating the MBMS UE Context is induced by entity of the SGSN or the UE. Once GGSN1 receives unsuccessful response message or the MBMS Activation Timer is overtime, the GGSN1 possibly will return back to the IP multicast access specifications described in 3GPP 29.061.
According to the description of IP multicast access specification described in 3GPP 29.061, under the circumstances of no MBMS bearer service, the GGSN has functions as an IP Multicast Agent, and the Point to Point (PTP) MBMS bearer service can be provided in UMTS network through the functions as follows:
a) a GGSN maintains a mobile station list including one or more multicast groups. When the GGSN receives an IGMP Joining or MLD Report from a mobile station, a list will be created/updated;
b) based on the maintained mobile station list, multicast routing information is transmitted to Packet Switched Domain routers to perform the routing of multicast packets;
c) once receiving the multicast packets, the GGSN will copy these packets and transmit the packets to each mobile station within the group through a PTP mode.
It is needed to explain that the MBMS bearer service is a type of User Service, which includes two implementing forms: an MBMS bearer service and a PTP unicast MBMS service.
Step 308: The SGSN implements such security functions as authentication to the current UE. This step can be omitted.
Step 309: After the SGSN confirms the particular GGSN which provides the requested MBMS bearer service according to the APN in Step 306, the SGSN creates an MBMS UE Context and transmits a Create MBMS Context Request to this GGSN. The Create MBMS Context Request includes an IP multicast address, an APN and an MBMS_NSAPI. In this embodiment, the GGSN practically providing the requested MBMS bearer service is GGSN2. Of course, GGSN1 and GGSN2 can be the same GGSN.
Step 310: GGSN2 transmits an MBMS Authorization Request to a BM-SC to quest the authorization for the UE, and the authorization judgment result is provided by an MBMS Authorization Response.
Step 311: If GGSN2 has no MBMS Bearer Context information of the MBMS bearer service, GGSN2 transmits an MBMS Registration Request to the BM-SC, and the corresponding procedures are described in MBMS registration procedure specification.
If the BM-SC has not assigned a TMGI for the MBMS bearer service, the BM-SC will assign a new TMGI which will be transferred to the GGSN and the SGSN through an MBMS Registration Response, further to the UE through an Activate MBMS Context Accept.
The BM-SC transmits MBMS Registration Response containing the MBMS Bearer Context of the MBMS bearer service to GGSN2 and adds GGSN2 to the List of downstream nodes of the MBMS Bearer Context. The corresponding procedures are described in MBMS registration procedure specification.
If GGSN2 has an MBMS Bearer Context of the MBMS bearer service, this step can be omitted.
Step 312: GGSN2 creates an MBMS UE Context and transmits a Create MBMS Context Response to the SGSN.
Step 313: If the SGSN has no MBMS Bearer Context of the MBMS bearer service, the SGSN will transmit an MBMS Registration Request to the GGSN, and the corresponding procedures are described in MBMS registration procedure specification.
GGSN2 responds an MBMS Registration Response, which includes the information of the MBMS Bearer Context of the MBMS bearer service, and adds the identification of the SGSN to the list of downstream nodes of the MBMS Bearer Context. The corresponding procedures are described in MBMS registration procedure specification. If the SGSN has an MBMS Bearer Context of the MBMS bearer service, this step can be omitted.
Step 314: If at least one Packet Switched Domain Radio Access bearer (PSRAB) is created for the UE, the SGSN provides the MBMS UE Context for the RAN.
Step 315: the SGSN transmits an Activate MBMS Context Accept to the UE which includes the MBMS Bearer Capabilities which is used to identify the maximum QoS of the MBMS bearer service. The UE may consider the MBMS bearer capabilities when it activates more MBMS bearer service. If the SGSN verifies that the MBMS bearer capabilities of the UE are less than Required MBMS Bearer Capabilities of current requested MBMS bearer service, the SGSN rejects the Activate MBMS Context Request, and indicates an indicated reason to start a deactivation process for the created MBMS UE Context.
It can be seen from the above flow, for the UE under all the circumstances, Step 315 must be the last step of the flow to verify whether the MBMS bearer capabilities of the UE are less than Required MBMS Bearer Capabilities of the current requested MBMS bearer service. For the UE that cannot meet the demand, since all bearers have been created for the UE through above procedures, a deactivation procedure is needed to be initiated to the UE.
As a network node without storing the Required MBMS Bearer Capabilities will have the Required MBMS Bearer Capabilities information just after once registration, if the procedure for a network node judging whether MBMS bearer capabilities of other UE are less than the Required MBMS Bearer Capabilities when other UE implements MBMS bearer service activation still carries out according to the above steps when other UE accesses, the steps are so complicated that network signaling interactions are increased and network efficiency is reduced.
It is mentioned in the Step 307 that the GGSN possibly returns back to the IP multicast access specifications described in 3GPP 29.061, but the IP multicast access specifications described in 3GPP 29.061 adopt PTP mode, which cannot save network resources and radio interface resources as PTM mode. Furthermore, during the above procedures, for the rejected UEs, no scheme of adopting other mechanisms to make the rejected subscribers receive requested MBMS bearer service is proposed, so the subscriber's satisfaction is greatly reduced.